# Matching existing move lines on statement lines
**URL:** https://discuss.tryton.org/t/matching-existing-move-lines-on-statement-lines/7993
**Category:** User
**Created:** [October 30, 2024, 2:45pm UTC](https://discuss.tryton.org/t/matching-existing-move-lines-on-statement-lines/7993 "2024-10-30T14:45:22Z")
**Posts on this page:** 10
**Page:** 2
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [October 31, 2024, 11:48am UTC](https://discuss.tryton.org/t/matching-existing-move-lines-on-statement-lines/7993/21 "2024-10-31T11:48:15Z")
> [@pokoli](#):
>
> If there is a single line matching the amount, it is not possible to match with the wrong party.
This is wrong.
Here is a simple and common example:
- Customer A is invoiced 2000€
- Customer B is invoice 1000€
Customer A does not have enough money on the due date but he wants to pay something anyway so he pays 1000€.
Now you are booking the 1000€ of Customer A to Customer B. #fail
> [@pokoli](#):
>
> I found several cases where the user creates a rule that does fuzzy matches and the proposal is not right. So any rule may be wrong.
I do not care as it is the responsibility of the user.
---
### Author:  [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [October 31, 2024, 11:58am UTC](https://discuss.tryton.org/t/matching-existing-move-lines-on-statement-lines/7993/22 "2024-10-31T11:58:45Z")
> [@ced](#):
>
> Customer A does not have enough money on the due date but he wants to pay something anyway so he pays 1000€.
In this case the customer will complaint, renegotiate the debt, the user should split the lines and as there are more than one line with the same amount it won’t match.
Even if he does not renegotiate in the next days Customer B will pay the invoice (or customer A will pay the remaining part) and then the user will notice the mistake and do the required fixes.
> [@ced](#):
>
> I do not care as it is the responsibility of the user.
It is always the responiblity of the user to check the lines created by the statement are correct. A ruling system will always make mistakes, no mather if you use the amount or any other criteria. This causes the follwoing problem:
> [@pokoli](#):
>
> the user does not have any way to know which lines have been manually reviewed and which ones are untrusted (create by the system).
The software should make the user life easier and give proper information so the user can decide he wants to review or what not.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [October 31, 2024, 12:03pm UTC](https://discuss.tryton.org/t/matching-existing-move-lines-on-statement-lines/7993/23 "2024-10-31T12:03:48Z")
> [@ced](#):
>
> And the “related to” is indeed optional and should probably not be filled when dealing with a high amount of lines (it is better to reconcile by account than by document).
But the “related to” could order the search result with the best match first (for example amount closest to the line amount).
> [@pokoli](#):
>
> In this case the customer will complaint, renegotiate the debt, the user should split the lines and as there are more than one line with the same amount it won’t match.
>
> Even if he does not renegotiate in the next days Customer B will pay the invoice (or customer A will pay the remaining part) and then the user will notice the mistake and do the required fixes.
I do not want a system broken this way.
Such justification could apply to anything so why would we care to make thinks right, the user could always fix it later.
> [@pokoli](#):
>
> It is always the responiblity of the user to check the lines created by the statement are correct.
Not if it is filled by the system automatically.
Otherwise there is no benefit for automation.
> [@pokoli](#):
>
> A ruling system will always make mistakes
No it depends on the rules implemented.
> [@pokoli](#):
>
> The software should make the user life easier
Not at the cost of mistakes and removing trust in the system.
> [@pokoli](#):
>
> give proper information so the user can decide he wants to review or what not.
There is no point to make wrong proposal.
_PS: I can not believe that I have to argument for a system that does not make mistakes._
---
### Author:  [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [October 31, 2024, 12:08pm UTC](https://discuss.tryton.org/t/matching-existing-move-lines-on-statement-lines/7993/24 "2024-10-31T12:08:23Z")
> [@ced](#):
>
> There is no point to make wrong proposal.
Then we must remove the statment rule module because there is the same possiblity that a rule is wrong that one matching by amount. Any rule may be wrong and we can not control if they will be right or wrong.
Furthermore, the user does not have any way to distingish what has be manually created (and thus should be trusted) that it has been automatically created and should be checked.
> [@ced](#):
>
> _PS: I can not believe that I have to argument for a system that does not make mistakes._
Do not understand this sentence, probably this is the main point while we do not understand each other.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [October 31, 2024, 12:58pm UTC](https://discuss.tryton.org/t/matching-existing-move-lines-on-statement-lines/7993/25 "2024-10-31T12:58:11Z")
> [@pokoli](#):
>
> Then we must remove the statment rule module because there is the same possiblity that a rule is wrong that one matching by amount. Any rule may be wrong and we can not control if they will be right or wrong.
For the last time, it is not the same if user creates loose rules and the system having a wrong matching result.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [October 31, 2024, 1:14pm UTC](https://discuss.tryton.org/t/matching-existing-move-lines-on-statement-lines/7993/26 "2024-10-31T13:14:11Z")
> [@albert](#):
>
> We implemented something in those lines in the [account\_statement\_enable\_banking module](https://github.com/NaN-tic/trytond-account_statement_enable_banking/blob/main/statement.py#L1815), and of course it would be great if something along those lines was considered into core.
This could be an option if the suggestion are filled with all the combination build using the non-unique results.
But using a `One2Many` is quite expensive and heavy. Also it does not work well with partial suggestion.
Indeed we may introduce a new concept for a field a little bit like the autocomplete but for suggestion. And instead of being displayed when the user is typing, it is display when the field is empty.
This way we could show for each field suggestion that the user has to pick.
---
### Author:  [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [October 31, 2024, 1:40pm UTC](https://discuss.tryton.org/t/matching-existing-move-lines-on-statement-lines/7993/27 "2024-10-31T13:40:38Z")
Won’t be easier to just create the line with a fuzzy flag?
We can prevent to post fuzzy lines and the user must check what is created by the system. Once the users checks everything is right the fuzzy flag is removed and the right values are posted.
---
### Author:  [@albert](https://discuss.tryton.org/u/albert)
#### Post date: [October 31, 2024, 1:56pm UTC](https://discuss.tryton.org/t/matching-existing-move-lines-on-statement-lines/7993/28 "2024-10-31T13:56:06Z")
> [@ced](#):
>
> This could be an option if the suggestion are filled with all the combination build using the non-unique results.
> But using a `One2Many` is quite expensive and heavy. Also it does not work well with partial suggestion.
>
> Indeed we may introduce a new concept for a field a little bit like the autocomplete but for suggestion. And instead of being displayed when the user is typing, it is display when the field is empty.
> This way we could show for each field suggestion that the user has to pick.
I understand One2Many is expensive but we make it even more expensive in the `account_statement_enable_banking` module 😂 because we make it a tree view.
Given that we work at the Origin level, we may suggest the user to create not one but several transactions for that origin. Clicking on the suggestion will create all the transaction lines at once.
For example, given an origin with 998€ we may suggest to put 1000€ linked to an existing invoice and -2€ to a bank commission account.
Using a tree view allows us to show several suggestions and the user can click on the “show children” icon and see what transactions will be made if she chooses that suggestion.
So yes, I agree it is expensive or heavy but we’d rather make user’s life easier.
Also, keeping that information in the database can help us improve suggestions in the future.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [October 31, 2024, 2:30pm UTC](https://discuss.tryton.org/t/matching-existing-move-lines-on-statement-lines/7993/29 "2024-10-31T14:30:43Z")
> [@pokoli](#):
>
> Won’t be easier to just create the line with a fuzzy flag?
It does not support multiple options.
And create more complex UI as there will be multiple “status”.
> [@albert](#):
>
> For example, given an origin with 998€ we may suggest to put 1000€ linked to an existing invoice and -2€ to a bank commission account.
I do not think booking bank fees is an option.
The statement origins must be filled correctly to represent the actual transactions not group them to ungroup them later.
> [@albert](#):
>
> Using a tree view allows us to show several suggestions
It is still possible with suggestions.
> [@albert](#):
>
> keeping that information in the database can help us improve suggestions in the future
You can still recompute the suggestions but I do not think it really important information for future training. The important data is correct values.
---
### Author:  [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [November 1, 2024, 2:31pm UTC](https://discuss.tryton.org/t/matching-existing-move-lines-on-statement-lines/7993/30 "2024-11-01T14:31:07Z")
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.
[Previous page](https://discuss.tryton.org/t/matching-existing-move-lines-on-statement-lines/7993.md?page=1)