Reconciliation model use case:
- No auto-validate
- No Match Invoice/bill fields set.
Expected result:
- The amls suggested should be as expected, i.e., do not filter for data that
is not defined in the reconciliation model.
TT52146
Related to 1db826b3c4
Backport of odoo/enterprise#64754.
This commit adds a CTE at the beginning of the invoice matching
amls candidate to speedup the whole query. More info and speedup
in PR above
Related to f396bc2f1f
Before, when using reconcile models that wanted to match invoice/bills
to statement based on the Label and/or Note and/or Reference, if there
is no real match with the statement label, the bank reco model would
mount/suggest another entry from the same partner.
This is misleading as we expect to be suggested with lines that actually
match with the statement, as stated in the reconciliation model.
Now, if any of the Invoices/bills matching rule is toggled, it will
suggest *only* matching amls. If no rule is toggled, it will behave like
before (mounting a match if any, or an aml from the same partner).
Related to 8948b31407
The orm doesn't match monetary amounts using the related currency.
It means, -208.73 != 208.730000000000002.
Let's match the amount using an sql query instead.
Related to ae848e9981
It seems some people are getting an "unassigned variable 'balance'".
This shouldn't happen with the standard code because _get_write_off_move_lines_dict is only
called from the manual reconciliation widget in which, you only have access to models having
strictly lines being percentage or fixed (see get_reconcile_modelds_for_manual_reconciliation).
This method is not called from the bank reco widget pointed by "RECONCILE x ITEMS" on the accounting dashboard.
It probably comes from some customization but I don't know which ones.
Related to 99525f8dac
Fix a decimal issue on reconciliation.
Steps:
- Set a reconciliation model with payment tolerance of 2%
- Create an invoice for $1210
- Create a bank stmt with a line for $1185.80
-> Reconciliation model is not apply
This is because of a decimal issue when calculating
the residual balance after reconciliation, leading to
the difference being 2.000000000000004% instead of 2%.
Related to d33e98b141
When the payment label is a single word, we try to match the full value and not only the alphanumeric values.
However, the matching was made on the token that was already sanitized using the [0-9a-zA-Z\s] regex.
Instead, let's match the full value.
Related to bccc0ae0e8
It can be that the name field on the account_move_line is an empty
string (as opposed to NULL). This can happen, for instance, when
generating the payment term line for Switzerland without the appropriate
fields on the company.
Since there are instances when the payment term's name is an empty
string, we can retrieve these lines and automatically match them with
payments from the bank reconciliation model. This can happen
automatically, with exact matches between a payment with a near-empty
reference (when the payment ref is just "/" or "?", this is sanitized
and ends up as an empty string for the purposes of comparison), and
these empty string payment term invoice lines.
The query that fetches the candidate lines for exact matches already
excludes those lines with a NULL move_line name, move ref, move name.
The natural extension of this behav
Related to ee22c02b1f
Making `SUBSTRING(REGEXP_REPLACE(LOWER(...), '[^0-9a-z\s]', '', 'g'), '\S(?:.*\S)*')` is costly in sql.
To avoid that, the tokens are computed python-side to avoid this extra processing.
Also, we want to avoid extra conditions on the tokens before executing the queries (and avoid it if necessary).
For example, we want to execute the query matching the sale orders only if at least one token is prefixed correctly by 'SO'.
Related to 76da4b055f
Some behavior were incorrect with reconciliation
rules:
1) Whit invoice_matching rule, no match_text_location
and no match partner set. Nothing was matching, even
by filling the right fields.
2) We were taking into account only the digits of the
payment reference of the invoice, by removing all
non digits characters. It has been decided to also
taking non digit strings from 'payment_ref' and 'ref'
into account, as long as they don't exceed one word.
Steps for point 1:
- Reco model with invoice_atching rule, payment_tolerance 0%,
no match_text_location and no match_partner
- An invoice for 100$ with name of the invoice as payment reference
(eg 'INV/2023/00001')
- A statement line of 100$ with either 'payment_ref, 'ref' or 'narration'
set as 'INV/2023/00001', and no partner
-> No match
Steps for point 2:
- Same reco model but with match_text_location_label set to True
- An invoice for 100$ with eg 'abcdef' as payment reference
- A statement line of 100$ with payment_reference (label) set
as 'abcdef' and no partner
-> No match
Related to cddea14954
* Create a reconciliation model that matches partners that have a
category `C`
* Create a bank statement and a partner that has *multiple* categories,
including C.
* Validate and reconcile
The reconciliation model you created should be used, but it is not.
Related to a0016fc6c9
We cant to avoid to change amounts on accounting entries during the reconciliation process. One of the goal is to avoid a following case :
The statement line is created in a foreign currency journal, later, the rate is updated in Odoo.
During reconciliation process, the partner is set on liquidity line, the accounting entries are synchronized and the balance changes.
We do not define partner_id with the value of manual_partner_id to prevent _synchronize_to_moves()
from making changes to the account.move.line leaving unintended values and/or data.
Re-define the value of reconcile_data_info if the _synchronize_to_moves() method has changed
anything on the lines.
Related to https://github.com/OCA/account-reconcile/issues/779
TT52634
Enric Tobella
OCA-git-bot
Víctor Martínez
oca-ci
mymage
Weblate
Jordi Ballester Alomar
Alexis de Lattre
Florian da Costa
Sergio Bustamante