The default group key is line number (or unequal), date and party. If user creates 2 lines with same number, date and party they are not grouped in a move if lines are not created in order, but they are if lines are created in order ...
The user creates 2 lines from a same origin because he needs to define 2 accounts but he wants the bank move to be grouped for this 2 lines.
I do not understand your argument, if the system will create a move for each line then why having a grouping method ...
Moreover depending on the order of line creation the system will have different behaviours. If user creates the lines with same number, party and date consecutively it groups, otherwise it does not group.
I do not see any problem because I do not see when such case would happen in a normal use case (not adding a similar line later).
My refection is purely based on the user experience and not at all about the implementation detail (I do not care that groupby is used or not). The experience is that a statement line that the system has split because it was linked for example to an invoice with a smaller amount, then the system will create only one account move in this case (I do not describe the experience in any way as a grouping behavior).
in our experience users prefer the statement creates account moves as image of bank transactions.
So if they have one bank transaction (statement origin) which pay 3 invoices (3 statement lines) they like to have one account move for this statement origin/transaction. In this move the will have the bank move line with total transaction amount and one move line per each statement line.
OK this is what I suspected.
The create_move should loop over grouped_lines such that origins order is used to guarantee the same grouping as in the report.
Indeed I'm closing it for now because I do not want to have to remember to do it later if you do not provide any use case example.
Fill free to reopen it if you have a use case.