After using the statement rule module we found that sometimes the name of the party does not match exactly the name of the the party. For example we found the following example:
Party Name: GAFAS KOST, S.L.
Name in statement: GAFAS KOST S.L.
Note that there thare is a coma in the party name which makes the search fail.
I’m wondering if we can find a way to make create a rule that also matches this cases.
Other cases that did not match:
Party Name: PEDRO MORENO VARGAS
Name in statement: PEDRO MORENO
I think the simplest and most reliable way is to create aliases as identifiers that match exactly the bank name.
That’s what we are already doing for the one’s with diferences. But I will expect that a submatch like:
It will work as this is works if the user enters the same text in the search party field of the statement origin.
Is there any reason to have such difference?
Yes we need exact matching without doubt because we do not want to generate any error. So we do not use wildcard in the search.
The only case we could improve is probably with punctuation but I do not know if we can determine which are the UTF-8 char that are punctuation to strip them.
Makes sense, the ones with different names can be added as identifier as already suggested.
From the cases we’ve found, normally the problems are with , . Ñ
For example we found also a party with Ñ in the name which was not included on the statement info.
I’m not sure if we should just strip them or replace with a single caracter wildcard. I propose the wildcard because it will match when the punctuaction is present but also when not.
I’m against using wildcard in standard because it is too fuzzy and may generate false positive.
Indeed it is of course better to import statement using a format that manage strict matching with for example the account number.
Maybe it could be help full to have a mechanism that store the relation between statement raw name and party. So when the user fix the party, the matching is store for future use.
That make sense for me, so once a rule matches we can store its keywords on the origin and use them to search non matching lines in the future.
While for our current case we only have the party keyword I think it can be designed on a generic way so the system will also learn for other keywords.
This will allow to pick also the account (and the party) from the existing lines.
To be honest, this is not the case of the AEB format used in Spain. The information is not structured and the data available depends on the bank you are working with.
Just written a quick test of this feature but I found that the keywords search does not work on sqlite (while it works on postgres). Is this a know limitation or something that should be fixed?
Just filled Issue 10518: Improve statement rule keyword matching - Tryton issue tracker which contains the feature fully implemented and ready to test!