Issue 10951

Title
Lines to pay unordered
Priority
feature
Status
testing
Nosy list
acaubet, ced, pokoli, reviewbot
Assigned to
acaubet
Keywords
review

Created on 2021-11-12.10:04:10 by acaubet, last changed 7 days ago by reviewbot.

Files

File name Uploaded Type Details
payment_amount.png acaubet, 2021-11-23.13:28:26 image/png view
Captura de pantalla de 2021-11-23 12-11-01.png acaubet, 2021-11-23.12:19:52 image/png view

Messages

Author: [hidden] (acaubet)
Date: 2021-11-26.10:39:41

I replaced debit and credit by amount because I though it's more clear and also is the same pattern as the party related "Payable/Receivable Lines".
Also added the payment_amount as suggested msg71789.
Added also the visual.

Author: [hidden] (pokoli) Tryton committer Tryton translator
Date: 2021-11-24.15:52:09

El 24/11/21 a les 15:33, Cédric Krier ha escrit:

I guess we could add the reconciliation as column so user may sort on it.

Yes, maybe this was not clear enought but our proposal was to include the default value for sorting and also the reconciliation column.

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2021-11-24.15:33:41

Now I guess we could add the reconciliation as column so user may sort on it.

Author: [hidden] (pokoli) Tryton committer Tryton translator
Date: 2021-11-24.14:40:47

Ok, so just add the visual indicator and leave the order.

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2021-11-24.14:22:08
On 2021-11-24 14:17, Sergi Almacellas Abellana wrote:
> Sincerly, I do not understand which is your main issue with ordering: 

Unstable and unnatural order.

> > But it breaks the planning and I doubt user will really understand such
> > virtual grouping
> 
> Could you clarify what do you mean by "it breaks the planning"? Of course, when a line has been rescheduled the original planning is broken and we do not care anymore about it because it has been rescheduled.

I expect a planning to be ordered by date.
Author: [hidden] (pokoli) Tryton committer Tryton translator
Date: 2021-11-24.14:17:28

But there are other cases where
to look at the lines to pay even when nothing was yet paid,
In such case the reconciliation order will not change anything (as eveything is unreconcilled so the order will be exactly the same as now).

or to find if some lines have not been reconciled with the wrong date etc.

In such case, reconciled lines will be shown together, so it will be easier to find if it was reconciled in a wrong date. So for me sorting on reconciliation also helps on this case.

As we are focused on lines_to_pay I think the reconciliation sort (with NULLS FIRST), it's always a good idea because it allows the user to cleary see what is pending to paid and which lines are paid by others.

Sincerly, I do not understand which is your main issue with ordering:

But it breaks the planning and I doubt user will really understand such
virtual grouping

Could you clarify what do you mean by "it breaks the planning"? Of course, when a line has been rescheduled the original planning is broken and we do not care anymore about it because it has been rescheduled.

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2021-11-24.14:04:40
On 2021-11-24 11:41, Sergi Almacellas Abellana wrote:
> Indeed I think the muted on reconciled line is a good idea because the user will see what is already paid but I still think that showing first unreconciled lines will help the user. It makes no sense to show first what is already paid and at the end (because split lines has no matturity_date) the payment lines.

I think your vision about the order is focussed on a single use case
which is to look what is not yet paid. But there are other cases where
to look at the lines to pay even when nothing was yet paid, or to find
if some lines have not been reconciled with the wrong date etc.
Author: [hidden] (pokoli) Tryton committer Tryton translator
Date: 2021-11-24.11:41:58

Indeed I think the muted on reconciled line is a good idea because the user will see what is already paid but I still think that showing first unreconciled lines will help the user. It makes no sense to show first what is already paid and at the end (because split lines has no matturity_date) the payment lines.

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2021-11-23.15:28:45
On 2021-11-23 13:28, Adrià Tarroja Caubet wrote:
> > For me account_payment should add the payment_amount field to the move_line_list_to_pay of the invoice.
> 
> I implemented what you mention, but I don't see the benefit of it (attached screenshot). How do you interpret this new column?

I think the debit/credit columns should also be replaced by amount.
So you will see for example on the first line that 60 has to be paid the
16th nov. and that 60 has still to be paid.

> The think here is to find a way to show clearly what is needed to pay.

On 2021-11-23 13:52, Sergi Almacellas Abellana wrote:
> > I do not think it really makes senses to order by reconciliation
> I makes sense when spliting the maturities of the invoice otherwise the user won't see which lines are already rescheduled and this is the objective of the issue.

So I would just set a muted visual on the line split. But I do not think
we can really distinct such lines. So it is probably simpler to apply on
reconciled lines.

> Probably this is not clear enougth, but our issue is raised **after doing the split payments wizard** and because the splited lines are shown in the view (which for me is OK). 
> 
> Ordering by reconciliation has two benefits: 
> 
> 1. We see first the lines that are really pending to be paid. 
> 2. Splited lines are grouped, so the user sees the full history of splits. 

But it breaks the planning and I doubt user will really understand such
virtual grouping.

> About payment amount i think it makes sense (but it solves another problem not related to this issue) so the user can see if there is some amount which is already in the payment workflow.

It will solve the comprehension because user will see muted line without
payment so he can understand that the line has been replaced.

> I guess on your screenshot there is any payment created for the lines, that's why the amount is exactly the same. Once a payment is created the payment amount will be less than the real amounts.

Probably that get_payment_amount should set the amount to 0 when it is
reconciled. It was not needed until now because this field was only
shown with a domain where reconciliation is None.
Author: [hidden] (pokoli) Tryton committer Tryton translator
Date: 2021-11-23.13:52:15

I do not think it really makes senses to order by reconciliation
I makes sense when spliting the maturities of the invoice otherwise the user won't see which lines are already rescheduled and this is the objective of the issue. Probably this is not clear enougth, but our issue is raised after doing the split payments wizard and because the splited lines are shown in the view (which for me is OK).

Ordering by reconciliation has two benefits:

  1. We see first the lines that are really pending to be paid.
  2. Splited lines are grouped, so the user sees the full history of splits.

About payment amount i think it makes sense (but it solves another problem not related to this issue) so the user can see if there is some amount which is already in the payment workflow. I guess on your screenshot there is any payment created for the lines, that's why the amount is exactly the same. Once a payment is created the payment amount will be less than the real amounts.

Author: [hidden] (acaubet)
Date: 2021-11-23.13:28:26

I still do not agree with this statement. A maturity date is valid for ever (not matter the reconciliation state). This will be always the date at which the line must/should have been reconciled.

Not saying that maturity date is not valid at all, it's something to record, but once is reconciled it's useful for history, nothing else as you say it shows the date which should have been reconciled.

For me account_payment should add the payment_amount field to the move_line_list_to_pay of the invoice.

I implemented what you mention, but I don't see the benefit of it (attached screenshot). How do you interpret this new column?

The think here is to find a way to show clearly what is needed to pay.

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2021-11-23.12:31:56

the maturity date of the reconciled line is no longer valid as something to pay

I still do not agree with this statement. A maturity date is valid for ever (not matter the reconciliation state). This will be always the date at which the line must/should have been reconciled.

For me account_payment should add the payment_amount field to the move_line_list_to_pay of the invoice.

Author: [hidden] (acaubet)
Date: 2021-11-23.12:19:52

I don't see ordering by maturity date as correct, the maturity date of the reconciled line is no longer valid as something to pay (obviously needs to be recorded there) but it's not useful.
I found more logic to quick find the not reconciled lines.
As you mention the issue10757, I tried to add Abs(line.credit - line.debit)._as('amount'), on the query selection but I don't really see the point for that.

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2021-11-12.10:29:34

I do not think it really makes senses to order by reconciliation. For me the default maturity date is correct.
Aso I do not think the reconciliation is the right thing to show. Indeed I would prefer to show the amount to pay each line like computed by issue10757.

Author: [hidden] (acaubet)
Date: 2021-11-12.10:04:08

After doing the invoices split lines to pay wizard. It shows all the lines without order, so it's so dificult when there are to much lines to know which is reconcilied.
The propose is to order by the reconciliation to see quick the matching lines and also show on the view the conciliation number.

History
Date User Action Args
2021-12-01 11:35:09reviewbotsetmessages: + msg71958
2021-11-26 10:59:23reviewbotsetmessages: + msg71867
2021-11-26 10:39:41acaubetsetcomponent: + account, account_payment
messages: + msg71865
2021-11-26 10:32:32reviewbotsetmessages: + msg71864
2021-11-26 09:36:17reviewbotsetmessages: + msg71862
2021-11-24 15:52:09pokolisetmessages: + msg71842
2021-11-24 15:33:41cedsetmessages: + msg71839
2021-11-24 14:40:47pokolisetmessages: + msg71836
2021-11-24 14:22:08cedsetmessages: + msg71834
2021-11-24 14:17:28pokolisetmessages: + msg71832

Showing 10 items. Show all history (warning: this could be VERY long)