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
Víctor Martínez
Pedro M. Baeza
Enric Tobella