This is wrong.
Here is a simple and common example:
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
I do not care as it is the responsibility of the user.
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.
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:
The software should make the user life easier and give proper information so the user can decide he wants to review or what not.
But the “related to” could order the search result with the best match first (for example amount closest to the line amount).
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.
Not if it is filled by the system automatically.
Otherwise there is no benefit for automation.
No it depends on the rules implemented.
Not at the cost of mistakes and removing trust in the system.
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.
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.
Do not understand this sentence, probably this is the main point while we do not understand each other.
For the last time, it is not the same if user creates loose rules and the system having a wrong matching result.
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.
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.
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.
It does not support multiple options.
And create more complex UI as there will be multiple “status”.
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.
It is still possible with suggestions.
You can still recompute the suggestions but I do not think it really important information for future training. The important data is correct values.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.