Grouping receivable/payable lines

Rational

Following One Payment for multiple Invoices

For now, a payment is linked to a single accounting line.
But sometimes to preserve the cash flow of a company, it is better to make a single payment which deduce existing receivable lines. (Or vice versa).

Proposal

We add a new wizard on the move lines (similar to the reconciliation wizard). It runs only with lines from the same party and on receivable or payable lines. It creates a new account move with counterparts lines for the selected lines and a new line with the sum on a selected receivable or payable (according to the sum sign) account (by default the one from the selected lines). The move date is today by the maturity date of the new line is the smallest maturity date of selected lines.

The wizard reconciles the selected lines with the counterpart lines but it should not mark the linked invoices as paid. So we add on the reconciliation model a field which delegate the reconciliation state to the linked line. This means that the invoice should not be considered as paid as long as this delegated lines is not also reconciled. The wizard will fill this field with the line with the sum.

The wizard is mainly usable from the view “Payable/Receivable Lines” from party. But in order to help the user, the “Pay Lines” wizard raises an warning when the user pays a line for a party which has also an opposite line that could be grouped. The warning key will be based on the party ID like that the user could skip the warning for the party only this time or always. If multiple lines for different parties are used, the wizard must raise a warning for each party.

Implementation

https://bugs.tryton.org/issue8213

Won’t be better to ask the new maturity date to the user?

Will this field be editable on the user interface or it should be only set when using the wizard?

for payments using SEPA/CFONB (in France), here is a link found to a brief describing

3.2.5 Guide «FacturesAcceptées à Echéance» (FAE)

https://gesimmo.qualiac.com/qualiac/hlp/qualiac/fr/oct/annexes/XML-TSEPC_pain.001.001.03_V2.1.pdf

BTW, this is just the initiation message… but that is probably the most important in terms of integration with this payment grouping.

The maturity date can be modified at any time so I think it is more user friendly to have on default and the smallest is the only sure option.

We do not allow to modify a reconciliation so I think it will only be available from this wizard or programmatically.

I agree with Sergi. For me it is more user friendly to ask the user the right values (probably with the defaults you suggest).

At least, that’s what we’re already using:

https://bitbucket.org/trytonspain/trytond-account_bank/src/ae4183843ca22fcadb4bd6ffec00100f401d63ff/account.py#lines-441

I do not understand the rational. What are the other possible dates?

I would say a normal scenario would be:

  • We have one invoice due to 30th March of 1000€
  • We have create a credit note on 4th March with due date 4th March of 100€. Usually the credit note due date will not follow the usual payment term for the customer given that it’s done to compensate some goods already delivered.

We agree with the customer that instead of paying on 4th March and later receive the payment, we will Direct Debit on 30th March 900€.

OK so the maturity should be the earliest date of the moves of the same sign as the sum.

and/or payable lines, no?
There needs to be a means possible to include invoices and credit notas, as well as the possibility to include compensated supplier with client invoices (or vice versa)…

Also, it is not quite clear to me how this integrates with account_payment_clearing,
wherein I would imagine the new line would end up in the clearing account if specified.

Yes.

No there is no link with the clearing because clearing is about registering payment before confirmation of the payment agency. Grouping receivable and payable lines is an internal operation on the accounting.

Then how to prepare a VCOM/FAE (or LCR/BOR) where all these elements need to be explicitly mentioned in the operation (not to mention on the sent or received [monthly] billing invoice statement?
Currently the grouping only allows either receivable or payable but not both. Is that going to be fixed separately?

Please avoid to use acronym (almost nobody understand them).

Which elements are you talking about?

This is exactly the purpose of this blueprint.

I am not using FAE or LCR directly (for others: the fact for a supplier to directly told the bank of his customer he wants to be paid for some invoices), but my suppliers did.

usually, I received a summary from my supplier with the list of invoices payable and receivable, with at end the total the supplier will ask to my bank.

and on the bank statement, I have only one amount for the group of payable/receivable invoices.

here it would be globally the same: the wizard permits to group a set of payable and receivable in order to have only one amount to pay/receive.

I dunno if a report could be done to summarize the operation and send it to the customer.

If it is about giving information about the origin of the paid line. The line will have a link to the reconciliation which will contain all the lines grouped (except the paid line). So the origins could be taken from there.
I think for example the sepa_remittance_information will be updated to follow the grouping.

VCOM/FAE = Commercial bank transfer / invoice payments accepted at due date
I cited a document upstairs. LCR/BOR are commercial paper that can be dematerialised
(LCR = exchange bills from supplier and BOR = promissory note)

each individual invoice needs to be mentioned along with its amounts which can be then be edited into a report justifying the net amount (balance).

noted above, thanks.

See Grouping receivable/payable lines - #14 by ced, the information will be available.

An implementation is available at Issue 8213: Allow to group payable and receivable lines - Tryton issue tracker

This topic was automatically closed after 14 days. New replies are no longer allowed.