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