One Payment for multiple Invoices


(Vincent Bastos) #1

It should be possible to link a payment to multiple Invoices move lines.

As it stands a payment record can only be linked to one invoice move line, but in real live it is possible to pay more than one invoice with a single payment.

(Sergi Almacellas Abellana) #2

One thing that we thought about payments is they it should be possible to join a list of payments into a single payment. So the idea was to create some wizard that groups multiple payments into a single one. Joined payments won’t be shown to the user, but only the parent payment (which has the total amount of the other payments).

When you perform some workflow action into the joined payment, then same workflow action will be called for its child payments.

If we do this way we can have the full traceabillity on the system.

Do you think this feature will solve your problem? In your case you should first create one payment for each of the invoices, and then group them using the wizard and manage only the parent payment.

(Vincent Bastos) #3


Since I made the post I actually thought that I could use the Group model in a similar way that you are suggesting. But your option seems interesting. I will consider it.

In any case, how do people use Tryton to pay multiple bills from a a single supplier for example? Do they have to make multiple payment records?

(Cédric Krier) #4

Yes or they can just make a payment without link to any lines. In the last case, it is only about working with the global amount to pay.

Support for global payment
(Vincent Bastos) #5

I don’t think that this solution is appropriate because the account move’s will not correspond to the reality.

But this means that in there will not be Reconciliations and the invoices will not be marked as being paid.

I think that the best solution would be to allow a many Reconciliations.

(Cédric Krier) #6

There is any way no reconciliation except if you use the clearing.
But as this way of working is based on the global amount to pay, the user should not care about the state of each invoice individually.
To implement this workflow, the account_payment module should deduce from the payable and receivable fields the pending payments. And it will need a wizard to create a payment for the remaining amount to pay or to receive.

At B2CK, we already tried to implement a payment with many lines. Such design is very fragile and lead to a very complex code that I do not think we should maintain.
My conclusion is that the company needs to decide which workflow it wants to follow: line by line or global, but it can not have a mix of both.

(Vincent Bastos) #7

Ok, I’ll keep thinking about this because without this feature it makes it difficult to use Tryton in Australia. We have a file format called ABA[1] which actually allows the creation of a single transaction that pays multiple people. In our bank statement, only one transaction appears, and in our accounting software we split up the payments. ( crazy I know,… but we are are down under ).


(Vincent Bastos) #8

I have another idea.

What about making the function “create_clearing_move()”[1] create multiple “counterpart” lines?


(Cédric Krier) #9

I do not understand how this can be possible. You have to tell to the bank who you are paying.
You can of course group many payments into on message like the SEPA does.

This is usually the case when using third party payment system like credit card etc. For example, you have only one transaction for the balance of the day. But this case is managed by the account_payment_clearing module which regroup all the payments into a single clearing account.

This does not make sense to me neither.

(Vincent Bastos) #10

I think that you have understood it, but you don’t want to believe it. I can try to get screen shots to show you, but otherwise it is exactly as you think. In our accounting software or even in our online banking portals we can create an “ABA” file just like a “SEPA” messages to pay multiple suppliers for example, BUT on our bank statements only 1 record will appear. This is the case whether you look at the online view or the printed statements.

Yes, I get that, but the scenario I am describing is not this.

Yes, I should probably suggest first that we change payment.line to become payment.lines.

(Cédric Krier) #11

So this is many payments grouped together. There is no need for the subject of this thread.

And this is solved by the clearing module.

(Vincent Bastos) #12

Perhaps the example of the ABA system is not the best example in relation to a possible solution for the one payment to multiple invoices.

Yes, I think I can see that working with the statement module. I’ll give that a try in relation to the “ABA” file example, but it’s not a solution for the main issue I’m trying to deal with - one payment for multiple invoices. I’ll continue to use payment groups for now.

(Richard PALO) #13

I think this is a good topic for the case of paying multiple invoices [ and credit notes] to [or even being paid from] the same party.

Monthly ‘statements’ (‘relevé’ ou ‘bordereau’ en français) are quite common practice providing a recap of the invoicing movements (NB invoices typically already recap the delivery notes/slips).

In fact, in France these are typically sent with an ‘LCR’ or bill of exchange (read ‘commercial paper’). There are also TIPs or Titres Interbancaire de Paiement (TIP-SEPA).

It seems that the ‘grouping’ could possibly be generalised prior to payment in order to generate the above mentioned ‘relevé’.

In the case of these bills with a future due date (à l’échéance), the French PCG has allocated special intermediate accounts ‘403xxx Fournisseurs - Effets à payer’ in parallel with the typical ‘401xxx Fournisseurs’.

For example, when signing and returning a bill of exchange one creates a movement C403xxx/[one or more D401xxx] such that at payment clearing only the single payment needs be reconciled (unfortunately I haven’t had opportunity yet to fully test account_payment_clearing to see how it works here).

Lefebvre* indicates that for EDIFACT commercial bank transfers (VCOM), a subdivision of 403 such as 4031xxxx Virements à Payer’ could be used similarly
Lefebvre* Comptable - Les opérations financières - Schémas usuels de comptabilisation

So, it appears that perhaps this intermediate ‘regrouping’ into ‘statements’, even if only internally used, could potentially solve numerous issues and even be quite useful to the SEPA payment/clearing module as well.


(Cédric Krier) #14

I do not think it is wise to move line from one receivable account to another receivable account because Tryton will only look at the initial move line for reconciliation to consider it as paid or not. For me, those intermediary accounts are created for manual accounting.
The SEPA module can group payment lines using the sepa_group_payment_key so I really thing it is still better to manage payment line by line.

(Richard PALO) #15

Perhaps I misunderstand your point, but at least in the French PCG and related laws, there is probably more ‘required’ to it than meets the eye.

If I don’t pay suppliers invoice(s) ‘cash’, but by other means then the invoice(s) are to be marked by a payment remittance movement (the ‘party’ is fully maintained on the movement)

This move (e.g. to 403xxx) notes this event and indicates that disbursement is pending (typically with specific due date) for bank clearing… (for details, see e.g. PCG Section 4 ‘Comptes de tiers (Classe 4) Fournisseurs et comptes rattachés (comptes 40)’ or the reference I already gave in Lefebvre )

As to SEPA bank payments, if the “Requested Execution Date” is in a future period, similar holds (because the credit transfer instruction is considered irrévocable).

There are probably those that don’t like to bother with any of this on a day to day basis, but it is mandatory … especially so at fiscal year-end closing for pending payments.

BTW: There is a catch, well, for partners and cash-basis for VAT anyway… whereas even though the “payment means” is accepted and irrevocable, only when the payment has cleared the bank (around the due date) and the remittance reconciled naturally that finally the invoice can be marked as paid.

This all is a frequent case encountered in France, for example in construction or other services industries where many payments are done by LCR/BOR and VCOM/FAE. (which is why I mentioned the possible feature for bank clearing in the first place, because it should be able to handle most all payment types, in theory at least).

(Richard PALO) #16

coming back to this subject… I’m tinkering with using account_payment_clearing with clearing account
(using ‘manual’ and not ‘SEPA’ ).

First observation is that, in a bank statement, I can select individual payment lines and get both the account and amount value, if I select a payment group only the clearing account is pulled in. ? something wrong?

Second observation is that I needed to unset ‘party required’ on the clearing account, though in the statement the party is correctly selected to this account!

Also, from the same supplier, I can select invoices in ‘Payable’, but his supplier credit notes are in ‘Receivable’ making it seemingly impossible to get into the same payment group…
Strange, the account kind is ‘payable’ so why does the payment processing change that, the amount of the credit note is to be deducted from the payment)… Naturally this can’t work if any given party’s selected invoices amount don’t cover his selected credit notes, but that’s a batch processing error case that should be caught.

Otherwise, things seem they should be okay for ‘manual’, making it possible to create a back-end to edit LCR/BOR and even VCOM/FAE.

Grouping receivable/payable lines
(Cédric Krier) #17

I think a solution would be to have a wizard that groups many receivable/payable lines into a new receivable or payable line (depending of the sum).
Such grouping will be done by creating a move with the counterparts of the selected lines and a sum line. The counterparts will be reconciled with each selected lines, leaving only the sum line non-reconciled. The move will be created under a selected journal.
The wizard can only work if all lines are from the same party.

In order to maintain the paid state on the invoice, the reconciliations will have a deferral field which will point to the sum line to indicate that it is the reconciled state of this line that must be taken into account.
If for some reason such deferred reconciliation would be deleted, we should raise a warning.

The wizard should propose a default account for the sum line according to the sign and using the same as the lines of the same sign but a different one could be selected. This will solve:

(Cédric Krier) #18

B2CK estimates at 16 hours the cost to develop this feature. We already have a customer that is willing to participate into this development. Thanks to contact B2CK if you want to join the effort.

(Sergi Almacellas Abellana) #19

Do you think it will be possible to add a new domain on Lines to Pay view to be show all the lines that is possible to group by this wizard? From the user point of view it will be great to show all the lines that is possible to group together in a same list.

(Cédric Krier) #20

For me, the “Payable/Receivable” link from the Party should be the entry point to such wizard.
Otherwise the user will need to filter/order the lines to pay by party.