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.
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.
Hey,
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?
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.
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.
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.
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 ).
[1] aba/sample-with-comments.aba at master · mjec/aba · GitHub
I have another idea.
What about making the function âcreate_clearing_move()â[1] create multiple âcounterpartâ lines?
[1] modules/account_payment_clearing: 416ca3910d79 payment.py
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.
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.
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.
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.
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.
cheers
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.
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).
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.
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:
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.
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.
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.