Room for improvement in reconcilation algorithm
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Account Banking Framework |
Fix Committed
|
Undecided
|
Unassigned |
Bug Description
Reconcilation algorithm bears some dangerous problems. I will describe just a few of them... I am now working on my own version for this part.
1.case: payment connected to the wrong partner, because search by invoice number matches wrong payment and no distinction by partner is ever being performed:
in database invoice number is "7", but in payment there is number "AB2342777" defined...
2.case: Matches outgoing payments to outgoing invoices, because no distinction by movement type and account type is ever being done.
3.case: Matches several payments from several partners to a movement of single invoice, not looking the total of the invoice or partner.
4.case: when there are several invoices with the same total, algorithm is unable to decide, because the matching is not being done in multiple stages.
there are much more cases, the algorithm now is unusable.
Related branches
Changed in account-banking: | |
importance: | Undecided → Medium |
I'm afraid no matching algorithm isn't going to be 'full proof' to cover all possibilities. Even humans make mistakes. I can see your point, but there is a reason why all this was coded the way it is.
1. This covers two cases:
a) The payer adds text to the reference number, say invoice was '2009.03' and payment says 'Factuur 2009.03'
b) There is a payer is a different party than the one the invoice was sent to, which is quite common.
This can be improved by requiring an exact match for b) and extending a) with a similarity match on name, although neither are very sound.
Also it helps big time to make your invoice references longer. The shorter, the greater chance of false positives.
2. When the invoice was credited, this is a valid match. Same for incoming payments and incoming invoices.
3. This creates false positives, indeed. Can be enhanced by keeping track of matched invoices. I'll pick that up.
4. I'm not sure I understand your point. Amount matching is only performed when no exact match on other identifiers can be made. When there are multiple identical positives within this context, I can see no way to make a safe and valid choice. If you have some smart ideas, I welcome your input.