Additional informations on Payment Group

accounting

(Sebastien Marie) #1

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.


(Cédric Krier) #2

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).

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.


(Sebastien Marie) #3

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.


(Sebastien Marie) #4

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

(Sergi Almacellas Abellana) #5

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.


(Cédric Krier) #6

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


(Sebastien Marie) #7

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

(Sergi Almacellas Abellana) #8

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.


(Sebastien Marie) #9

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.


(Sebastien Marie) #10

I created issue7890 and attached a patch.