Additional informations on Payment Group

[semarie (Sebastien Marie)]

Rational

Currently, payment Group have only few information directly available to the user:

• the group number
• the journal used
• the kind of operation (receivable or payable)

When manipulating Group (via Statement for example), choosing the right Group couldn’t easily be done, as all Group are showed, and information directly available is inexistant (only the number is usually useful).

Proposal

Adding some computed fields on Group could be easily done.

• count : number of payments associated to the group.
• amount : the total amount of the payments associated to the group.
• paid amount : the total amount of the succeeded payments associated to the group.
• complete : boolean for marking the group when all payments are in successed or failed state.

Having the complete field searchable would permit to filter out Group which have been already completed.

Implementation

Implementing the proposal via Function fields should be straightful (with only getter, so read-only fields).

The fields would be displayed on form and list for Group.

For searchable complete field, it could be using a stored Boolean instead of a Function.

https://bugs.tryton.org/issue7890

[ced (Cédric Krier)]

@semarie

state : let the user know about the state of associated payments. For the Group it should be:

• processing : all payments are in processing state. It means no action has been initiated.
• partially processing : some payments (but not all) are in successed or failed state.
• completed : all payments are in successed or failed state.

I’m wondering if it will not be better to have just two Boolean fields: complete (all in either succeeded or failed) and processing (any in processing).

@semarie

Having the state field searchable would permit to filter out Group which have been already completed.

I guess it is doable to write the searcher but maybe it will be expensive to join with all payments. In this case it is probably better to store the field on group and update when payment workflow change.

[semarie (Sebastien Marie)]

@ced

I’m wondering if it will not be better to have just two Boolean fields: complete (all in either succeeded or failed) and processing (any in processing).

From database point of view, it could be better, specially if we have to store the completed information. But for displaying the information to the user, I am unsure as it means showing 2 booleans. Just having a textual information like state seems more simple for the user point of vue.

[semarie (Sebastien Marie)]

@semarie

But for displaying the information to the user, I am unsure

after doing some tests, I think the user interface is readable with booleans, but not with processing boolean as defined. in fact, there is no difference for the user if only some payments in the group are completed (partially completed) or if none are completed (all in processing state). so I would propose to have 2 booleans like the following:

• partial : the group is partially completed. some, but not all, payments are in succeeded or failed state
• complete: the group is completed. all payments are in succeeded or failed state

[pokoli (Sergi Almacellas Abellana)]

@semarie

• partial : the group is partially completed. some, but not all, payments are in succeeded or failed state
• complete: the group is completed. all payments are in succeeded or failed state

I think we should only care for non complete groups. So I’m wondering if it will be enough with only one Boolean field to know if the group is completed or not.

[ced (Cédric Krier)]

Indeed maybe we could have two amounts: total of all payments and total of succeeded. Then a single complete boolean should be enough.

[semarie (Sebastien Marie)]

I have updated the proposal:

• no more state
• instead of use 2 amounts: “total amount” and “paid amount” (for succeeded payments)
• only one boolean complete which should be searchable

[pokoli (Sergi Almacellas Abellana)]

@semarie

count : number of payments associated to the group.

Why should be useful to have the number of payments?
Isn’t enough adding having the amount of payments?

The number of payments can be easly obtained by double clicking the group as all the payments of this groups will be opened.

[semarie (Sebastien Marie)]

@pokoli

Why should be useful to have the number of payments?

mostly for quickly have the information. It is useful for preparing check deposit at bank, or for retrieving sepa payment (with the total amount and number of operations).

but I agree the number could be obtained by reading the number of records when opening the payments of the group. so it is just a little more convenient.

[semarie (Sebastien Marie)]

I created issue7890 and attached a patch.

[risto3]

This work is welcome! Has it been updated since the last comments on the issue?

BTW, for the cases with sepa payments, it would be nice to add as well the ‘PmtInfId’ value
as that seems to show up in bank statements as the reference.

[semarie (Sebastien Marie)]

if I recall correctly, I was stopped by the need to add EVERY support in py-sql. I could try to revisit it.

Currently I am using it as part as a local module.

[risto3]

@risto3

BTW, for the cases with sepa payments, it would be nice to add as well the ‘PmtInfId’ value
as that seems to show up in bank statements as the reference.

I just realised that this currently isn’t feasible:

• because in sepa payments, the ‘PmtInfId’ seems to be nothing more than the payment date (output using date.toordinal() in method sepa_group_payment_id())
• and because a list is displayed and not a tree which would permit easily seeing which payments are included in the group.

Perhaps if a tree view was displayed, the group details could add this column (sepa_group_payment_id).

[risto3]

@semarie

if I recall correctly, I was stopped by the need to add EVERY support in py-sql. I could try to revisit it.

maybe the MIN(CASE …) workaround as indicated in the web article Cédric referenced can do the job in the meanwhile…